tests: add OS_IMAGE_TYPE setting to allow for minimal tests #5682
Conversation
| # image-type lookup for daily_image and released_images. | ||
| # | ||
| # One of the following: | ||
| # - generic |
There was a problem hiding this comment.
Where do these names come from? I assume that this is a pycloudlib construct? Can we please include a pointer to wherever in pycloudlib this is documented to ease future maintenance of this?
There was a problem hiding this comment.
These come from the ImageType enum in pycloudlib. (pycloudlib.cloud.ImageType)
There was a problem hiding this comment.
Nice work on this @blackboxsw! I left a fix inline to address @holmanb's question.
Also, would you mind updating the integration docs to cover this new configuration option? Here's a patch to get you started (or if you think it is sufficient, just ship it 🫡)
diff --git a/doc/rtd/development/integration_tests.rst b/doc/rtd/development/integration_tests.rst
index aecb02244..a51657797 100644
--- a/doc/rtd/development/integration_tests.rst
+++ b/doc/rtd/development/integration_tests.rst
@@ -284,6 +284,31 @@ variable to be the desired image specification.
OS_IMAGE = 'jammy'
+To run integration tests on a specific type/family of image, modify the
+``OS_IMAGE_TYPE`` variable to be the desired image type. This comes from
+pycloudlib's ImageType enum, which can take the following values:
+
+- "generic"
+- "minimal"
+- "Pro"
+- "Pro FIPS"
+
+.. tab-set::
+
+ .. tab-item:: Inline environment variable
+
+ .. code-block:: bash
+
+ CLOUD_INIT_OS_IMAGE_TYPE='minimal' tox -e integration_tests
+
+ .. tab-item:: user_settings.py file
+
+ .. code-block:: python
+
+ OS_IMAGE_TYPE = 'minimal'
+
+Note: Not all clouds and images support all image types
+
Image setup
===========| # image-type lookup for daily_image and released_images. | ||
| # | ||
| # One of the following: | ||
| # - generic |
There was a problem hiding this comment.
These come from the ImageType enum in pycloudlib. (pycloudlib.cloud.ImageType)
| # - minimal | ||
| # - Pro | ||
| # - Pro FIPS | ||
| OS_IMAGE_TYPE = "generic" |
There was a problem hiding this comment.
We keep talking about additional OS support, and this one comes across as being Ubuntu-specific in a way that might encourage a bunch of OS-specific fields to proliferate across various OSes. We could try to encode this into OS_IMAGE, but I'm also wondering if it might be time for a new abstraction for all the various ways of specifying an image (e.g., differentiating amd64/arm is on the horizon too).
I think I'm ok with this now, but if we have to add another dimension to our image specification, I think we need a better solution.
There was a problem hiding this comment.
@TheRealFalcon: from the looks of other distribution vendors , there are similar alternative "offers" such as BYOS (bring your own subscription) images, HA and minimal images. I wonder if it is worth representing an optional "::offering" segment in
OS_IMAGE of the format
<image_id>[::<os>::<release>::<version>[::<offer-name>]]
This way we'd still have the ability to configure a known offer stream of images for Ubuntu, without bloating integration-settings.py options with yet another config param.
In the absence of offer-name, we'd assume generic, otherwise any string could be provided. From Ubuntu perspective, we could provide (generic|minimal|Pro|Pro FIPS). In the future, other vendors could provide BYOS, minimal, OSA(openshift app), etc.
For other distro support, I think we may have to rethink how we use pycloudlib.cloud.ImageType and maybe rename that OfferType to better align with how clouds label separate product images from vendors.
There was a problem hiding this comment.
After spending some time on this proposal. I can reject my suggestion for optional <offer_name> suffix in OS_IMAGE for two reasons:
- offer names are actually platform/cloud specific. A "minimal" image offer in EC2 will not have the same offer/product name in Azure or GCP. The pycloudlib.cloud.ImageType interprets image types per cloud to provide the right mapping of ImageType to cloud offering/product/image stream so that the integration test runners don't have to have detailed knowledge of a certain flavor/offer name or image per-platform.
- providing an optional
<offer_name>suffix in OS_IMAGE also requires making<image_id>::a leading optional value ofNoneornullin order to provide a trailing<offer_name>. This leads to complexity of image specification where it can take either 4 or 5 parts, and significant documentation around when to use the optional leadingNone::
For these reasons, I think it makes sense to stick with a new OS_IMAGE_TYPE config value (or we could call it IMAGE_FLAVOR) to better represent this unique image stream.
Allow setting CLOUD_INIT_OS_IMAGE_TYPE="mimimal" to support running the full integration test suite against Ubuntu minimal images. Required for SC-1750: Daily jenkins ubuntu minimal test runner for Ubuntu Focal, Jammy and Noble releases.
blackboxsw
force-pushed
the
SC-1750-lxd-minimal-integration-testing
branch
from
746a75a
to
5af25f0
Compare
github-actions
bot
added
the
documentation
Proposed Commit Message
Additional Context
https://warthogs.atlassian.net/browse/SC-1750
Depends on canonical/pycloudlib#410
After the above this PR and the pyclluldlib PR merge, a serserver-jenkins-jobs matrix will be configured to run LXDContainer jobs against ubuntu-minimal:(focal, jammy, and noble)
Test Steps
Merge type